Proposal: move win32-loader in SVN repository - Debian

This is a discussion on Proposal: move win32-loader in SVN repository - Debian ; win32-loader was included in the repository in packages/arch/i386, but IMO that is not correct. Reason I feel it is not correct is that, although it is definitely related to D-I, it is not a D-I component (does not produce udebs). ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

Thread: Proposal: move win32-loader in SVN repository

  1. Proposal: move win32-loader in SVN repository

    win32-loader was included in the repository in packages/arch/i386, but IMO
    that is not correct. Reason I feel it is not correct is that, although it
    is definitely related to D-I, it is not a D-I component (does not produce
    udebs).

    I thought that the location was chosen so that translating it could be
    integrated, and I thought that was already the case. Yesterday I learned
    that this is not so.
    I also personally feel that translation of win32-loader should not be
    integrated in the level 1 infrastructure _because_ it isn't a D-I
    component.

    I therefore propose to move win32-loader (and any tags) from its current
    location to directly under trunk, as is suitable for a basically
    independent package.
    This would also make it more clear that translations need to be committed
    separately and makes it easier for translators to do a separate checkout of
    just win32-loader if they like. For translation statistics win32-loader
    could be included in level2, together with other packages that are
    important for installations.

    When busybox (currently under people/waldi) is moved to trunk, it should IMO
    also go directly under trunk.

    Cheers,
    FJP

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH5VbTgm/Kwh6ICoQRAuOVAKCU4h1ZMQR3k2hke+Jm3UzQpWVCZQCffIZR
    mw+ePrzr/24EgXUo7TKD4Ho=
    =iJO9
    -----END PGP SIGNATURE-----


  2. Re: Proposal: move win32-loader in SVN repository


    Hi Frans,

    On Sat, Mar 22, 2008 at 07:58:18PM +0100, Frans Pop wrote:
    > win32-loader was included in the repository in packages/arch/i386, but IMO
    > that is not correct. Reason I feel it is not correct is that, although it
    > is definitely related to D-I, it is not a D-I component (does not produce
    > udebs).
    >
    > I thought that the location was chosen so that translating it could be
    > integrated, and I thought that was already the case. Yesterday I learned
    > that this is not so.


    I expected that translation would be integrated eventually. Christian
    mentioned there are technical problems with that. I'm willing to help on
    those if I can, but we haven't got around to discussing it yet (it wasn't
    a big priority for me either).

    > I also personally feel that translation of win32-loader should not be
    > integrated in the level 1 infrastructure _because_ it isn't a D-I
    > component.


    You mean that because win32-loader doesn't produce udebs, it can't be
    considered a D-I component, and therefore its translations can't be integrated?

    Is this based on the assumption that only udebs provide programs that interact
    with the user during the install process?

    --
    Robert Millan

    I know my rights; I want my phone call!
    What use is a phone call… if you are unable to speak?
    (as seen on /.)


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Proposal: move win32-loader in SVN repository

    PLEASE do NOT CC me on list mail!

    On Saturday 22 March 2008, Robert Millan wrote:
    > > I thought that the location was chosen so that translating it could be
    > > integrated, and I thought that was already the case. Yesterday I
    > > learned that this is not so.

    >
    > I expected that translation would be integrated eventually. Christian
    > mentioned there are technical problems with that. I'm willing to help on
    > those if I can, but we haven't got around to discussing it yet (it wasn't
    > a big priority for me either).


    As win32-loader does not follow the usual structure of D-I components there
    will always be exceptions. I see no reason to force our translation
    infrastructure into supporting that when translations can easily be handled
    outside D-I, just as is already done for some other packages that are
    related to D-I, but not part of it in a strict sense (such as aptitude or
    tasksel).

    > > I also personally feel that translation of win32-loader should not be
    > > integrated in the level 1 infrastructure _because_ it isn't a D-I
    > > component.

    >
    > You mean that because win32-loader doesn't produce udebs, it can't be
    > considered a D-I component, and therefore its translations can't be
    > integrated?


    No, you are twisting my argument.

    > Is this based on the assumption that only udebs provide programs that
    > interact with the user during the install process?


    Besides the fact that that statement is already completely untrue (even if
    you don't consider win32-loader), that has nothing to do with it and
    nothing I said could have given you that impression.


    win32-loader is IMO not part of the installer _in a strict sense_. Of course
    it _is_ very closely related to it and therefore I have no problem with
    having it in the D-I repository.

    I just feel that _given_ that it is not really part of D-I itself, _given_
    that it does not produce udebs, _given_ that translations are not currently
    part of level 1 (which confused at least me as a translator!) and
    exceptions would have to be coded to make it part of it and _given_ that we
    already have excellent alternative ways to deal with such packages, my
    conclusion is that it should not be in its current location in the
    repository, but rather at the top level.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH5YPzgm/Kwh6ICoQRAhm9AKCzdrobF3ztWNFw9oei82DnJ68pBACfRK/X
    A4VUCzQBPbT6ajdTgO3EOnE=
    =Z7mr
    -----END PGP SIGNATURE-----


  4. Re: Proposal: move win32-loader in SVN repository

    On Sat, Mar 22, 2008 at 11:10:51PM +0100, Frans Pop wrote:
    > On Saturday 22 March 2008, Robert Millan wrote:
    > > > I thought that the location was chosen so that translating it could be
    > > > integrated, and I thought that was already the case. Yesterday I
    > > > learned that this is not so.

    > >
    > > I expected that translation would be integrated eventually. Christian
    > > mentioned there are technical problems with that. I'm willing to help on
    > > those if I can, but we haven't got around to discussing it yet (it wasn't
    > > a big priority for me either).

    >
    > As win32-loader does not follow the usual structure of D-I components there
    > will always be exceptions. I see no reason to force our translation
    > infrastructure into supporting that when translations can easily be handled
    > outside D-I, just as is already done for some other packages that are
    > related to D-I, but not part of it in a strict sense (such as aptitude or
    > tasksel).


    Ok, no big deal.

    > > > I also personally feel that translation of win32-loader should not be
    > > > integrated in the level 1 infrastructure _because_ it isn't a D-I
    > > > component.

    > >
    > > You mean that because win32-loader doesn't produce udebs, it can't be
    > > considered a D-I component, and therefore its translations can't be
    > > integrated?

    >
    > No,


    Then why do you keep talking about udebs?

    > you are twisting my argument.


    You overestimate me. I can barely understand your argument, let alone
    twist it.

    Anyway, no big deal for me as I said.

    --
    Robert Millan

    I know my rights; I want my phone call!
    What use is a phone call… if you are unable to speak?
    (as seen on /.)


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Proposal: move win32-loader in SVN repository

    (I follow up in the original proposal instead of the following thread,
    which I read, though)

    Quoting Frans Pop (elendil@planet.nl):
    > win32-loader was included in the repository in packages/arch/i386, but IMO
    > that is not correct. Reason I feel it is not correct is that, although it
    > is definitely related to D-I, it is not a D-I component (does not produce
    > udebs).
    >
    > I thought that the location was chosen so that translating it could be
    > integrated, and I thought that was already the case. Yesterday I learned
    > that this is not so.


    Frankly, I don't really remember whether the package was put there
    with the idea of integrating it in the translation infrastructure or
    not.

    I don't really think so because just like you:


    > I also personally feel that translation of win32-loader should not be
    > integrated in the level 1 infrastructure _because_ it isn't a D-I
    > component.



    This is also my feeling.

    I agree that we had a brief exchange, Robert and I, two days ago,
    about possibly integrating it in master files (after all, it could go
    in one of the sublevels...). But, thinking deeper, this is not really
    a good idea, for the reasons you mentioned.

    >
    > I therefore propose to move win32-loader (and any tags) from its current
    > location to directly under trunk, as is suitable for a basically
    > independent package.
    > This would also make it more clear that translations need to be committed
    > separately and makes it easier for translators to do a separate checkout of
    > just win32-loader if they like. For translation statistics win32-loader
    > could be included in level2, together with other packages that are
    > important for installations.



    Actually, when the package was introduced, I *briefly* added it as
    part of level 2. However, there's a problem: some languages are not
    supported in NSIS. So, as the comments in the win32-loader say: one
    has first to translate NSIS before working on win3-loader.

    As NSIS is something we don't have control over, I thought it would be
    unfair for translators of those languages to include the language in
    level 2 while they practically *can't* really translate for their
    language.

    For this reason, adding win32-loader to level 2, which we try to get
    complete when we release, is IMHO too much.

    I would welcome any idea as this situation is indeed something that I
    don't really like.

    About the package move, I support Frans suggestion: keep the package
    in D-I SVN, but in a tree that would be parallel to packages.

    By the way, it could be interesting to talk about moving tasksel there
    as well. Having it separated is mostly historical but the package is
    D-I team maintained for ages and is closely related to D-I anyway.



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH5fyU1OXtrMAUPS0RAk6JAKCxRVrn0W72AijBJq7y5L DWUWDj3QCdFmTv
    ErZ4rlynUKQC9Iwjw3mDpw4=
    =5CZU
    -----END PGP SIGNATURE-----


  6. Re: Proposal: move win32-loader in SVN repository

    On Sun, Mar 23, 2008 at 07:45:40AM +0100, Christian Perrier wrote:
    > >
    > > I therefore propose to move win32-loader (and any tags) from its current
    > > location to directly under trunk, as is suitable for a basically
    > > independent package.
    > > This would also make it more clear that translations need to be committed
    > > separately and makes it easier for translators to do a separate checkout of
    > > just win32-loader if they like. For translation statistics win32-loader
    > > could be included in level2, together with other packages that are
    > > important for installations.

    >
    >
    > Actually, when the package was introduced, I *briefly* added it as
    > part of level 2. However, there's a problem: some languages are not
    > supported in NSIS. So, as the comments in the win32-loader say: one
    > has first to translate NSIS before working on win3é-loader.
    >
    > As NSIS is something we don't have control over, I thought it would be
    > unfair for translators of those languages to include the language in
    > level 2 while they practically *can't* really translate for their
    > language.


    Sounds like a fair point (as for udebs, I still don't really see how they
    relate to the equation, but that is moot now).

    I'm not familiar with what each level means, though. Is there a less-priority
    level for which it would be suitable?

    My interest in integration is due to other things not related to how much
    priority is assigned to translating win32-loader. For example, new translators
    often use the BTS to send win32-loader translations, but it would be more
    convenient if they use the same channels used to add stuff to packages/po/
    (sometimes this even meant that translator coordinators sent bug reports
    instead of committing the translation directly).

    So, is there any solution that would allow this, without imposing win32-loader
    translations as a prioritary requirement?

    --
    Robert Millan

    I know my rights; I want my phone call!
    What use is a phone call… if you are unable to speak?
    (as seen on /.)


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: Proposal: move win32-loader in SVN repository

    Quoting Robert Millan (rmh@aybabtu.com):

    > Sounds like a fair point (as for udebs, I still don't really see how they
    > relate to the equation, but that is moot now).
    >
    > I'm not familiar with what each level means, though. Is there a less-priority
    > level for which it would be suitable?


    Well, not easily..:-)

    I personnally think that translating win32-loader should be a quite
    high priority for translators. Something equivalent to level 2,
    indeed. But, on the other hand, I don't want to clutter level 2 stats
    with it....because, as already explained, there are languages that
    are/have been 100% for level 2 but *don't* have NSIS translated. So it
    wouldn't be fair for these to include win32-loader to level 2

    This is also not only about being "fair" but make my own task easier
    during the final release process. During that process, I try as much
    as possible to get level 2 completed, nagging translators very hard to
    get them to 100%. It would be more complicated to have some languages
    for which the target is not 100% but, say, 82%, because these
    languages do not have win32-loader support.

    As a compromise, I could maybe add win32-loader to level 3 (along with
    xorg, menu....).

    >
    > My interest in integration is due to other things not related to how much
    > priority is assigned to translating win32-loader. For example, new translators
    > often use the BTS to send win32-loader translations, but it would be more
    > convenient if they use the same channels used to add stuff to packages/po/
    > (sometimes this even meant that translator coordinators sent bug reports
    > instead of committing the translation directly).



    Well, having it in any level will not help much there. It will help
    for translators who read docs or read mails in debian-i18n. BUt you'll
    still get some bug reports.

    Anyway, as there is no perfect solution, my best proposal currently is
    moving the package either directly under trunk/ or into an "otherpkgs"
    directory parallel to packages/ (in case we decide to put something
    else in D-I SVN. And, simultaneously, add win32-loader to level 3.



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH5pD61OXtrMAUPS0RAmxsAJ9rhWkKeu3TVVU1YDV5Gq zHLIgTxACgqej4
    9MbWr2IDDOzic6zIO4FRqUA=
    =SV8M
    -----END PGP SIGNATURE-----


  8. Re: Proposal: move win32-loader in SVN repository

    On Sun, Mar 23, 2008 at 06:18:50PM +0100, Christian Perrier wrote:
    > Quoting Robert Millan (rmh@aybabtu.com):
    >
    > > Sounds like a fair point (as for udebs, I still don't really see how they
    > > relate to the equation, but that is moot now).
    > >
    > > I'm not familiar with what each level means, though. Is there a less-priority
    > > level for which it would be suitable?

    >
    > Well, not easily..:-)
    >
    > I personnally think that translating win32-loader should be a quite
    > high priority for translators. Something equivalent to level 2,
    > indeed. But, on the other hand, I don't want to clutter level 2 stats
    > with it....because, as already explained, there are languages that
    > are/have been 100% for level 2 but *don't* have NSIS translated. So it
    > wouldn't be fair for these to include win32-loader to level 2
    >
    > This is also not only about being "fair" but make my own task easier
    > during the final release process. During that process, I try as much
    > as possible to get level 2 completed, nagging translators very hard to
    > get them to 100%. It would be more complicated to have some languages
    > for which the target is not 100% but, say, 82%, because these
    > languages do not have win32-loader support.
    >
    > As a compromise, I could maybe add win32-loader to level 3 (along with
    > xorg, menu....).
    >
    > >
    > > My interest in integration is due to other things not related to how much
    > > priority is assigned to translating win32-loader. For example, new translators
    > > often use the BTS to send win32-loader translations, but it would be more
    > > convenient if they use the same channels used to add stuff to packages/po/
    > > (sometimes this even meant that translator coordinators sent bug reports
    > > instead of committing the translation directly).

    >
    >
    > Well, having it in any level will not help much there. It will help
    > for translators who read docs or read mails in debian-i18n. BUt you'll
    > still get some bug reports.
    >
    > Anyway, as there is no perfect solution, my best proposal currently is
    > moving the package either directly under trunk/ or into an "otherpkgs"
    > directory parallel to packages/ (in case we decide to put something
    > else in D-I SVN. And, simultaneously, add win32-loader to level 3.


    Ah, sorry I think I didn't understand well. My idea of "integration" was that
    the strings were merged with other components of the same level in a single
    PO file. Now that I check, this only applies to level 1 sublevels, right?

    But well, I think it still would be nice to be in level 3 :-)

    So where do we move it to, trunk/win32-loader? trunk/otherpkgs/win32-loader...?

    --
    Robert Millan

    I know my rights; I want my phone call!
    What use is a phone call… if you are unable to speak?
    (as seen on /.)


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: Proposal: move win32-loader in SVN repository

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Robert Millan writes:

    > So where do we move it to, trunk/win32-loader? trunk/otherpkgs/win32-loader...?


    Alternatives that comes to my mind are:

    extrapackages/
    extrapkgs/
    otherpackages/
    otherpkgs/
    relatedpackages/
    relatedpkgs/

    relatedpkgs/ is my preferred one... others?

    - --
    O T A V I O S A L V A D O R
    - ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    - ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Processed by Mailcrypt 3.5.8+

    iD8DBQFH5q+dLqiZQEml+FURApR1AJ9/GnTFEhSFuwfMYiw2OsiKXXTeTwCdF8Q+
    BcKwxdCuhdFmXn5nW6wXxkU=
    =wvtC
    -----END PGP SIGNATURE-----


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: Proposal: move win32-loader in SVN repository

    On Sunday 23 March 2008, Robert Millan wrote:
    > So where do we move it to, trunk/win32-loader?


    For now this has my strong preference, partially because we just have too
    few such packages to worry about cluttering the top level.

    Note that existing tags will need to be moved at the same time!

    If no-one objects, I will move win32-loader directly below trunk in a couple
    of hours.

    Cheers,
    FJP

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH5rp+gm/Kwh6ICoQRAiR+AJ0b6VuHPSMiDtfLVR1yIR1w32gaJQCgjBu8
    v7vT2kTdB6t4y/IbjC+t9Gs=
    =T0Yo
    -----END PGP SIGNATURE-----


  11. Re: Proposal: move win32-loader in SVN repository

    Frans Pop writes:

    > On Sunday 23 March 2008, Robert Millan wrote:
    >> So where do we move it to, trunk/win32-loader?

    >
    > For now this has my strong preference, partially because we just have too
    > few such packages to worry about cluttering the top level.
    >
    > Note that existing tags will need to be moved at the same time!
    >
    > If no-one objects, I will move win32-loader directly below trunk in a couple
    > of hours.


    If we're going to move tasksel (maybe others) there, maybe would be
    better to decide where to put them all together.

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Re: Proposal: move win32-loader in SVN repository

    On Mon, Mar 24, 2008 at 09:34:14AM -0300, Otavio Salvador wrote:
    > Frans Pop writes:
    >
    > > On Sunday 23 March 2008, Robert Millan wrote:
    > >> So where do we move it to, trunk/win32-loader?

    > >
    > > For now this has my strong preference, partially because we just have too
    > > few such packages to worry about cluttering the top level.
    > >
    > > Note that existing tags will need to be moved at the same time!
    > >
    > > If no-one objects, I will move win32-loader directly below trunk in a couple
    > > of hours.

    >
    > If we're going to move tasksel (maybe others) there, maybe would be
    > better to decide where to put them all together.


    Please settle on something before moving ...

    --
    Robert Millan

    I know my rights; I want my phone call!
    What use is a phone call… if you are unable to speak?
    (as seen on /.)


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. Re: Proposal: move win32-loader in SVN repository

    On Monday 24 March 2008, Robert Millan wrote:
    > Please settle on something before moving ...


    Already done as announced, but if need be it can be moved again.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH5943gm/Kwh6ICoQRAih/AJ9FKpnwm04aNgqwMtRwrP5Zx1swLgCgyJiw
    q0zzcOqOpDIdlKKsfAs1gvU=
    =9xnm
    -----END PGP SIGNATURE-----


  14. Re: Proposal: move win32-loader in SVN repository

    On Monday 24 March 2008, Otavio Salvador wrote:
    > If we're going to move tasksel (maybe others) there, maybe would be
    > better to decide where to put them all together.


    I'm personally not in favor of moving tasksel to D-I.
    D-I SVN is not "all your source are belong to us"...

    We already have a significant maintenance burden as a team, I don't see why
    we should add to it by moving anything that's remotely related to the
    repository. If we do, we might as well also include apt and aptitude.

    I'm also concerned about the size of the checkout, which is huge already.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH599rgm/Kwh6ICoQRAkjCAJ9MMhQ2ndhvGaOpZUauezW+9d8/xQCfQ3+6
    Ihu45cMzxf4imTSo21A7XwY=
    =zg/x
    -----END PGP SIGNATURE-----


  15. Re: Proposal: move win32-loader in SVN repository

    Joey Hess wrote:
    > Independent of repository, I have no problems with tasksel being moved
    > from the tasksel alioth package to the d-i one, if managing its committers

    ^^^^^^^
    project
    > is an issue.


    --
    see shy jo

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH6Chfd8HHehbQuO8RAtMKAJ9X/L6ccIY9iNkXh2adH1pknP/hUQCeObZ7
    uL+UGQjofji7bZu0cJcwopk=
    =/7rx
    -----END PGP SIGNATURE-----


  16. Re: Proposal: move win32-loader in SVN repository

    Christian Perrier wrote:
    > Well, I volunterily launched this, about tasksel because I feel like
    > the package is, in reality, maintained by the D-I team since about
    > 2004.
    >
    > Joey is definitely the one who bringed the most to it (working on it
    > with big "hops") so I think he should have the last work on this.
    >
    > Pros: l10n, definitely. Translators are the same ones and the only
    > ones who aren't allowed to tasksel but are for d-i are those I
    > forgot to add
    >
    > Cons: Frans argument is valid, certainly. We don't want to give this
    > feeling and if someone wants to step deeper into tasksel, we don't
    > want to prevent him|her to do so.


    I would much rather not merge independent repositories into the d-i svn
    repository, since they will have to be split out again if/when we move
    to git or other distributed revision control systems.

    Independent of repository, I have no problems with tasksel being moved
    from the tasksel alioth package to the d-i one, if managing its committers
    is an issue.

    --
    see shy jo

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH6Cd0d8HHehbQuO8RAmIbAJ959r7hY1vHfvjeW6G6XF 3W8tXmNwCgqLba
    tMc9Eg9983rduUAwANuY0i8=
    =an+S
    -----END PGP SIGNATURE-----


  17. Re: Proposal: move win32-loader in SVN repository

    Quoting Joey Hess (joeyh@debian.org):

    > Independent of repository, I have no problems with tasksel being moved
    > from the tasksel alioth package to the d-i one, if managing its committers
    > is an issue.


    This is an issue...but probably not important enough alone to motivate
    a move.

    That's a though call here but I suggest we don't do the move because
    the given arguments are not convincing enough for the main tasksel
    developer..:-)

    Thank you, Joey, for your answer.



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH6JRI1OXtrMAUPS0RAhTLAKCVV90MdXNOcetXh/yB4dyXuyTiUACgiSBy
    ZjdM9YyefU4ay9o54g6vva4=
    =Zoo/
    -----END PGP SIGNATURE-----


  18. Re: Proposal: move win32-loader in SVN repository

    FWIW, I think this move of win32-loader is pretty silly, both from the
    perspective of why we originally decided to have a packages/ subdirectory,
    and in that it seems to assume win32-loader is a special case, which it
    isn't -- mklibs, kernel-wedge, debian-installer, and
    debian-installer-manual also live in-tree w/o producing udebs.

    --
    see shy jo

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH6Vogd8HHehbQuO8RAgAYAKDB3vv364VKcVr+PDhKuX fSOujDgACeNOjw
    FHk7hzPSPhAbkuBmEEsXdfI=
    =GV0W
    -----END PGP SIGNATURE-----


  19. Re: Proposal: move win32-loader in SVN repository

    On Tue, Mar 25, 2008 at 04:01:36PM -0400, Joey Hess wrote:
    > FWIW, I think this move of win32-loader is pretty silly, both from the
    > perspective of why we originally decided to have a packages/ subdirectory,
    > and in that it seems to assume win32-loader is a special case, which it
    > isn't -- mklibs, kernel-wedge, debian-installer, and
    > debian-installer-manual also live in-tree w/o producing udebs.


    I think it deviated too much from the initial issue at hand, which was
    translation integration. Well, I guess if it was clear before that its
    translations couldn't be integrated, it is a bit more clear now! ;-P

    Anyway, if you later decide that it ought to move again, please do CC me,
    as I'd have to update the reference in http://goodbye-microsoft.com/source.html

    --
    Robert Millan

    I know my rights; I want my phone call!
    What use is a phone call… if you are unable to speak?
    (as seen on /.)


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  20. Re: Proposal: move win32-loader in SVN repository

    On Tuesday 25 March 2008, Joey Hess wrote:
    > FWIW, I think this move of win32-loader is pretty silly, both from the
    > perspective of why we originally decided to have a packages/
    > subdirectory, and in that it seems to assume win32-loader is a special
    > case, which it isn't --


    > mklibs


    Agreed. I already proposed (on IRC) to move that to directly below trunk as
    well. Bastian replied that then lib-di should be moved as well, but that's
    not comparable

    So, unless there are strong objections I will also move mklibs.
    busybox, which is currently in people/waldi, should also be moved directly
    below trunk when Bastian is ready to move it out of his people dir.

    > kernel-wedge


    True, but that is so closely related to the kernel-*-di-* components that
    its current location does make sense.

    > debian-installer, and debian-installer-manual


    And these already do live directly below trunk...

    > also live in-tree w/o producing udebs.


    One of my arguments was that translators can expect a package under
    packages/ to be integrated in the D-I translation infrastructure, which is
    just not the case for win32-loader. Having it directly under trunk makes
    the package a lot more accessible and makes it clear to translators that it
    _is_ a separate package.

    So, I really don't think "silly" is appropriate here.

    Cheers,
    FJP

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH6XBpgm/Kwh6ICoQRAukUAKCNi1n6O9Tn8IDajNGRd4Z8EJIFTgCfVo8g
    x+vSf2i9JoZ8svBscJFP2yY=
    =oSZj
    -----END PGP SIGNATURE-----


+ Reply to Thread
Page 1 of 2 1 2 LastLast