public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin-apps@cygwin.com
Subject: Re: Planned setup.ini changes for early 2018
Date: Sat, 13 Jan 2018 18:35:00 -0000	[thread overview]
Message-ID: <871sit7gji.fsf@Rainer.invalid> (raw)
In-Reply-To: <5e585f56-b4b1-753d-7ca8-0f7894194fa9@dronecode.org.uk> (Jon	Turney's message of "Wed, 10 Jan 2018 22:44:49 +0000")

Jon Turney writes:
> * De-duplicate source archives
>
> Source archives which are identical[2] between x86 and x86_64 will be
> moved to paths starting src/ in the release area.

You keep acting like using a new src/ hierarchy was already decided
upon, yet I don't remember it even getting discussed.  So, can we have
that discussion before decision, please?

To repeat, I think a separate src/ hierarchy would be a mistake, given
where we are today, although it has a certain appeal from a greenfield
perspective.  But more to the point, there is nothing special about
source archives (except that they're not architecture specific) that
warrants putting them into their own hierarchy, IMHO.  If they are going
to get moved on deduplication (there are good reasons to move them and
these likely outweight the benefits of just deleting them in one side of
the hierarchy), we already have a place for that and that place is
noarch/.  That keeps everything in working order for folks who for
whatever reason mirror the repository, even if the only mirror one
architecture.  If we also agree to actually move the files from a
specific architecture branch to noarch/, any mirror operator can
pre-populate the noarch/ hierarchy in order to minimize the amount of
data to get synchronized (I suggest using x86_64).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

  parent reply	other threads:[~2018-01-13 18:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 22:44 Jon Turney
2018-01-10 23:27 ` David Stacey
2018-01-13 17:21   ` Jon Turney
2018-01-11 17:55 ` Peter A. Castro
2018-01-12 15:48   ` Jon Turney
2018-01-12 18:13     ` Peter A. Castro
2018-01-13 17:22       ` Jon Turney
2018-01-11 18:30 ` Achim Gratz
2018-01-13 18:43   ` Achim Gratz
2018-01-13 18:35 ` Achim Gratz [this message]
2018-01-15 19:02   ` Jon Turney
2018-01-16 18:12     ` Achim Gratz
2018-01-22 23:13 ` Jon Turney
2018-01-23 18:30   ` Achim Gratz
2018-01-24 20:30     ` Jon Turney
2018-01-24 20:57       ` Achim Gratz
2018-01-28 15:07   ` Jon Turney
2018-03-01 16:01 ` Jon Turney
2018-03-01 16:39   ` Marco Atzeri
2018-03-01 17:02     ` Jon Turney
2019-05-30 14:08   ` Jon Turney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871sit7gji.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).